Data securing communication apparatus and method

ABSTRACT

An object to be encrypted is decided in accordance with the type of input data and transfer characteristic of a network connected, and communication is performed with a communication mate by sharing parameters including an encryption object range and a data verification range in accordance with the object to be encrypted.

TECHNICAL FIELD

The present invention relates to communication apparatus and method thatprovide data security against eavesdropping and falsification byencryption and authentication of the transmission data.

PRIOR ART

IP (Internet Protocol) networks, typified by the Internet, are notinherently equipped with security features. If no prevention measuresare taken, it would be possible to eavesdrop and modify the contents ofcommunication without arousing the notice of the parties concerned withthe communication by the acquisition or alteration of the IP packetduring transmission. Therefore, security protection is crucial for thetransmission and reception of important information about businesstransactions or the like on the IP network.

For example, in content delivery services that deliver music and videothrough the Internet, the music and video data to be delivered arevaluable important information and need to be protected againstinterception and falsification during transmission. And, in the VoIPsystem that offers telephone services through the IP network, it isnecessary to prevent illegal eavesdropping of the contents ofcommunication.

In the VoIP system and in a streaming content delivery system, RTP/UDPis commonly used as shown in FIG. 1A for the transmission of datarequired to be real-time. RTP (Real time Transport Protocol) is aprotocol that is used in an application layer 11 and is suitable forreal-time processing. UDP (User Datagram Protocol) is a connectionlessprotocol that is used in a transport layer 12 which is an interfacebetween the application layer 11 and a network layer 13.

A transmission packet according to this system comprises, for example,as shown in FIG. 2, an IP header 13H, a UDP header 12H, an RTP header11H and an RTP payload 11PL. Since RTP/UDP is intended for real-timepacket transmission rather than for ensuring packet transmission likeTCP (Transmission Control Protocol, a connection-type protocol that isused in the transport layer), there is a possibility of the occurrenceof a packet loss during transmission. For this reason, measures againstthe packet loss should be taken into account on the occasion of studyingthe security scheme for application to RTP/UDP.

Further, it is also important to apply security techniques to mobilecommunications now quickly spreading. For RTP/UDP packet transmission ina mobile communication network, headers of both of the RTP packet (RTPheader+RTP payload) and the UDP packet (UDP header+RTP packet)compressed in a radio link with a view to improving the utilizationefficiency of the radio transmission band. Accordingly, it is to bewished that the security scheme, especially, the encryption system beone that allows header expansion/compression of the RTP/UDP packet inlinks halfway through transmission.

As a secure RTP packet transmission system for application to mobilecommunication networks, Secure RTP (SRTP, see: draft-ietf-avt-srtp-00.txt) has been proposed by IETF (Internet Engineering Task Force). InSRTP there have been introduced a selective encryption system thatallows header compression and an encryption system that lessens theinfluence of the packet loss or bit error. That is, the RTP packet isprocessed, as depicted in FIG. 3, by encrypting only the RTP payload11PL, and generating and adding a data authentication code(authenticator) 11A to the encrypted RTP payload 11PL and the RTP header11H so that the validity of data of the RTP header 11H and the encryptedRTP payload 11PL can be verified. This technique permits efficientprotection but RTP-specific.

That is, Secure RTP necessitates the use of an RTP-specific encryptionalgorithm and encryption parameter, and hence it cannot be utilized forapplications and transport protocols on other UDP systems. Since itsselective encryption parameter and encryption algorithm are fixed,Secure RTP cannot deal with new protocols and hence it is not suited tocontent delivery that makes rapid progress. A security techniquespecialized for a particular application, as mentioned above, is notpreferable since it is necessary to study an individual securitytechnique each time a new application is developed. Further, althoughthe security technique is not permanent, Secure RTP has its encryptionalgorithm fixed and hence raises a problem in terms of security.

On the other hand, SSL (Secure Socket Layer) (TSL) is now widely used asa security technique on the Internet. When SSL (TSL) is not used,applications in layer 11, such as HTTP (Hypertext transfer Protocol),FTP (File Transfer protocol) and Telnet (remote log-in), are connecteddirectly to a TCP or UDP transport layer 12 as shown in FIG. 4A. Incontrast thereto, SSL is a security protocol that is located between theTCP or UDP transport layer 12 and the application layer 11 as depictedin FIG. 4B. SSL provides a secure data transmission service to theapplication layer by performing some security processing of data that issent and received through utilization of the data transmission functionoffered by TCP or UDP. Therefore, there is no limitation to applicationand encryption algorithm to be utilized. SSL is in wide use particularlyfor an HTTP session in a Web access, but it can also be used versatilyfor other applications of FTP and Telnet. Moreover, there is proposed,as a modified version of SSL for mobile communication use, WTLS(Wireless Transport Level Security) standardized in the WAP (WirelessApplication Protocol) Forum.

SSL and WTLS generally have a two-layer configuration as depicted inFIG. 5. The protocol that is used in the lower layer 11S2 in thetwo-layer configuration is called Record Protocol, and it offersfacilities for encrypting protocol data of the upper layer 11S1 andadding a data authentication code (MAC). The upper layer 11S1 in thetwo-layered configuration of SSL contains four kinds of protocols, ahandshake protocol HSP (Handshake Protocol), an alert protocol ALP(Alert Protocol), a change cipher protocol CCP (Change cipher Protocol)and an application data protocol ADP (Application Data Protocol). Thehandshake protocol HSP possesses negotiation facility of anencryption/data authentication scheme and terminal/serverauthentication; the alert protocol ALP possesses an event and errorindicating facility; and the change cipher protocol CCP possesses afacility of validating an negotiated encryption/authentication scheme.The application data protocol for indicating the start of encryptedcommunication to the other party is to transparently send and receiveupper-layer application data; HTTP or FTP data in the application layer11 is provided via this protocol to the record protocol (RecordProtocol) 11S2.

FIG. 6 shows an example of the data configuration that is sent andreceived between record protocols (Record Protocols) of the sending andreceived sides. In a header 20H there are contained an identifier(Protocol type) 21 indicating the kinds of upper-layer protocols (suchas handshake, alert and application data), an SSL version (MajorVersion, Minor Version) 22, and data lengths (Length (high), Length(low)) 23A and 23B. A payload 24 is encrypted upper-layer protocol data;the encrypted data 24 contains a data content (Content) 24A and anauthenticator MAC 24B for verifying the validity of the data content andthe header. This configuration is applied to all protocols that utilizethe record protocol 11S2, including the application data protocol.Accordingly, in the case of transmitting the RTP packet by use of SSL,the header and the payload in their entirety are encrypted and mappedinto the payload 24 of the record protocol data.

When the header of the record protocol is added to such an encryptedversion of the whole RTP packet or the RTP packet, it is impossible toperform RTP header compression during transmission. That is, since theheader compression is performed collectively for the RTP header, the UDPheader and the IP header arranged one after another as depicted in FIG.2, if a record protocol header 20H is inserted between the RTP headerand the UDP header, they cannot collectively be data-compressed. Forthis reason, the application of SSL/WTSL to the RTP packet protection isnot desirable in mobile communications.

In common data communications, too, it would be convenient if only aparticular portion desired to protect could be secured by encryption orauthentication for verification of its validity, but it has beendifficult to adaptively provide security.

An object of the present invention is to provide a data-securingcommunication apparatus and method that permit communication with onlypart of input data selectively secured.

DISCLOSURE OF THE INVENTION

According to the present invention, the communication apparatus at thesending side shares parameters indicating a securing target of inputdata with a data-securing communication apparatus at the receiving sidevia a communication channel, and selectively secures part of the inputdata according to the shared parameter, thereafter outputting the data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a diagram showing processing that does not use Secure RTP.

FIG. 1B is a diagram showing processing that uses Secure RTP.

FIG. 2 is a diagram depicting an example of packet configuration.

FIG. 3 is a diagram depicting data configuration of a selectivelyencrypted packet.

FIG. 4A is a diagram showing application data processing that does notuse SSL/WTLS.

FIG. 4B is a diagram showing application data processing that usesSSL/WTLS.

FIG. 5 is a diagram showing particulars of the SSL/WTLS layer.

FIG. 6 is a diagram showing the configuration of record protocol dataprocessing by SSL/WTLS.

FIG. 7 is a diagram illustrating the functional configuration of anembodiment of this invention apparatus and an example of the systemconfiguration in which this invention apparatus is used.

FIG. 8 is a diagram showing examples of encryption parameters.

FIG. 9 is a flowchart showing an example of an encryption range sharingprocedure at the transmitting side.

FIG. 10 is a flowchart showing an example of an encryption range sharingprocedure at the receiving side.

FIG. 11 is a flowchart showing an example of the procedure of anencryption/authenticator adding part 33 in FIG. 7.

FIG. 12 is a diagram depicting an example of the data configuration ofthe output packet from the encryption/authenticator adding part 33.

FIG. 13 is a flowchart showing another example of the procedure of theencryption/authenticator adding part 33.

FIG. 14 is a flowchart showing an example of procedure of this inventionmethod.

FIG. 15 is a diagram illustrating the functional configuration of asecond embodiment of this invention apparatus.

FIG. 16 is a diagram illustrating the functional configuration of athird embodiment of this invention apparatus.

BEST MODE FOR CARRYING OUT THE INVENTION

First Embodiment

FIG. 7 illustrates a first embodiment of the present invention and thegeneral outline of a data transmission system using the embodiment.

A data-securing communication apparatus 30 of the present invention, forexample, at such a transmitting side as a server or data terminal and adata-securing communication apparatus 40 of the present inventionsimilarly at such a receiving side as a server or data terminal can beconnected via a communication network 50. The communication network 50is shown as one network, but it may also be formed by plural networkssuch as a combination of a public communication network and theInternet.

The data-securing communication apparatus 30 in this embodiment has, assecuring means, an encryption/authenticator adding part 33 between anapplication part 31 and a transport part 32. And, a parameter sharingpart 34 is provided as an upper layer of the transport part 32. Thetransport part 32 has a TCP or UDP function and is connected, forexample, to a network part 35 equipped with an IP function, and thenetwork part 35 is connected to a transmitting-receiving part 36 that isa physical layer, and the transmitting-receiving part 36 is connected tothe communication network 50.

The data-securing communication apparatus 40 is substantially identicalin configuration with the data-securing communication apparatus 30; thatis, it is provided with an application part 41, a transport part 42, anetwork part 45 and a transmitting-receiving part 46, and in thisembodiment, a decoding/verification part 43 is provide as securingmeans, and a parameter sharing part 44 is provides as an upper layer ofthe transport part 42.

Prior to the transmission of application data from the application part31, the communication apparatus 30 negotiates with the counterpartapparatus 40 about parameters necessary for data security, that is,parameters necessary for encryption processing/data authenticator (code)generation processing, and shares these parameters with the counter partapparatus 40. The parameters are: information for specifying which ofalgorithms Null, DES, 3DES, RC4 and so on is used; secret informationfor key generation; random values for encryption/decryption orauthentication/verification in the communication apparatus 30 (forexample, a server apparatus) and the communication apparatus 40 (forexample, a client apparatus); the range over which to encrypttransmission data; and the range of data authentication.

In this embodiment it is particularly important that the parameters forspecifying the range of encryption and the range of data authenticationare newly provided as shared parameters, and the other parameters areshared in the same way as that for shared parameters used in securingprotocols by conventional SSL (TSL) scheme; sharing of these parametersis performed by intercommunication between the communication apparatuses30 and 40 via the communication channel as is the case with conventionalSSL scheme.

In this case, the newly shared parameters which indicate the securingtarget of data to be transmitted—the range of encryption and the rangeof data authentication in this example—are information for determiningthe range over which it encrypt and authenticate the input data packet(data packet from the application part 31 in this example), and variousmethods are possible for specifying the range; for example, information“start encryption at such and such a byte from the beginning of thepacket” is used to specify the range.

Further, the range of encryption and the range of data authenticationare determined according to the kind of input data, that is, theapplication in this example, or according to the transmissioncharacteristics (such as the transmission rate, delay characteristic,transmission error characteristic, attenuation characteristic, frequencycharacteristic and distortion characteristic) of the communicationnetwork 50 to which the communication apparatus 30 is connected.

The parameter sharing part 34 of the communication apparatus 30determines sharing of the parameters indicative of the securing target,for example, by the procedure shown in FIG. 9. On receiving a requestfor encrypted communication (S1), the parameter sharing part: makes acheck to see if the input data application packet is an RTP packet (S2);if it is an RTP packet, makes a check to see if the communicationnetwork 50 to which the apparatus 30 is connected is a network of lowtransmission rate, for example, a mobile communication network (S3); andif it is a mobile communication network, transmits to the othercommunication apparatus 40 encryption/authentication parametersindicating selective encryption of the RTP packet (indicating, forexample, that the RTP header at the beginning of the input data isexcluded from encryption) (S4). At this time, other parameters, such asthe encryption algorithm and the data authenticator generationalgorithm, are also sent.

On the other hand, upon receiving the encryption/authenticationparameters from the communication apparatus 30 (S1) as shown, forexample, in FIG. 10, the parameter sharing part 44 of the communicationapparatus 40: makes a check to see if the receivedencryption/authentication parameters are those for selective encryptionof the RTP packet (S2); if so, determines that theencryption/authentication parameters in the parameter sharing part 44are those for RTP packet selective encryption (S3); and sends thedetermined encryption/authentication parameters to the communicationapparatus 30 (S4).

On receiving from the communication apparatus 40 theencryption/authentication parameters indicating RTP packet selectiveencryption (S5) as shown in FIG. 9, the parameter sharing part 34 of thecommunication apparatus 30 determines the encryption/authenticationparameters as the target of RTP packet selective encryption (S6). Inthis way, the both parameter sharing parts 34 and 44 share the RTPselective encryption as the encryption/authentication parameters via thecommunication channel. Incidentally, the encryption algorithm and otherparameters are similarly determined at the same time. In this instance,as is the case with conventional SSL, for instance, several candidatesfor each parameter are sent to the apparatus 40 for determination.

In FIG. 9, when it is decided in step S2 that the input data is not anRTP packet, or when it is decided in step S3 that the transmission rateof the communication network 50, to which the communication apparatus 30is connected, is high, the communication apparatus sends to thecounterpart 40 encryption/authentication parameters indicatingencryption of the whole input data (packet), that is, indicatingnon-selective encryption (S7).

As depicted in FIG. 10, when it is decided in step S2 that theencryption/authentication parameters are not for RTP packet selectiveencryption, the parameter sharing part 44 of the communication apparatus40: decides whether the input data (application) from the applicationpart 41 of the communication apparatus 40 is an RTP packet (S5); if itis an RTP packet, makes a check to see if the communication network 50to which the communication apparatus 40 is connected is, for example, amobile communication network of low transmission rate (S6); and if so,goes to step S3, in which it determines the encryption/authenticationparameters indicating RTP packet selective encryption and sends it tothe communication apparatus 30 (S4). When it is decided in step S5 thatthe input data is not an RTP packet, or when it is decided in step S6that the communication network 50 is not a mobile communication networkwhose transmission rate is not low, the parameter sharing partdetermines encryption/authentication parameters indicating non-selectiveencryption (S7), and sends the parameters to the communication apparatus30 (S4).

As depicted in FIG. 9, upon receiving the encryption/authenticationparameters from the communication apparatus 40 (S8) after thetransmission in step S7, the parameter sharing part 34 of thecommunication apparatus 30: makes a check to see if the receivedencryption/authentication parameters are those for RTP packet selectiveencryption (S9); if so, goes to step S6, in which the parameter sharingpart determines the encryption/authentication parameters as those forRTP packet selective encryption; and if not for RTP packet selectiveencryption, determines the encryption/authentication parameters as thosefor non-selective encryption (S10).

In this way, the parameter sharing parts 34 and 44 can share the rangeof encryption via the communication channel. The range of authenticationis set to be the whole input data irrespective of the input data(application) and independently of the transmission characteristic ofthe communication network 50 to which the communication apparatuses 30and 40 are connected. The range of encryption can be specified not onlyas to whether to exclude the header from encryption but also as desired.For example, when the input data is image or audio data, it is alsopossible to limit the range of encryption specifically to an importantportion which, if lost, would make decoding impossible. In either case,the encryption algorithm and other parameters are also subjected tosharing processing simultaneously with sharing of the range ofencryption.

When the parameters are shared as described above, they are provided tothe encryption/authenticator adding part 33 and thedecoding/verification part 43 from the parameter sharing parts 34 and44, respectively.

The encryption/authenticator adding part 33 performsencryption/authenticator adding processing. An example of the proceduretherefor is shown in FIG. 11. When input from the upper application part31 (S1), a data packet is transparently input to theencryption/authenticator adding part 33 by an application data protocol(S2), and an authenticator is generated by a shared authenticatorgenerating algorithm/authenticator generating key by use of that portionof the data packet selected according to the authentication rangeparameter (S3). The authenticator generating method is described indetail, for example, in IMAI Hideki, “Lecture on Cryptography,” Section4.7. The authenticator is generated, for instance, by compressing theauthentication range data by a hash function and encrypting thecompressed data by the common key. Then the authenticator is added tothe input data packet (S4), and that port of the authenticator-addeddata packet which is selected based on the encryption range parameter isencrypted using the shared encryption algorithm and encryption key (S5).Incidentally, in the case of block encryption, padding is carried outprior to the encryption in anticipation of the shortage of data for thefixed block length (S6).

In FIG. 12 there is shown an example of the configuration of suchencrypted data. In this example the authenticator MAC is added to theinput application data 11D, and the portion (payload) of the applicationdata, except the header 11DH, and the authenticator MAC are encrypted.The selectively encrypted data is provided to the lower transport part32, from which it is sent to the other communication apparatus 40.

The receiving-side communication apparatus 40 decodes the encrypted datafollowing the procedure reverse to that described above, and thevalidity of the received data is verified by use of the dataauthenticator (code). That is, in the communication apparatus 40 in FIG.7, the packet received from the communication apparatus 30 is input fromthe transport part 42 to the decoding/verification part 43, and in thedecoding/verification part 43 the encrypted portion is selectivelydecoded according to the shared encryption algorithm, encryption key andrange of encryption, and the data authenticator (code) MAC in thedecoded data is used to verify the validity of the header and thedecoded payload, that is, the application data in FIG. 12. Theapplication data, if valid, is supplied to the application part 41.

By such sharing of the range of encryption, it is possible toselectively encrypt part of the input data; for example, encryption ofonly that portion of the input data whose security becomes an issuemakes the workload lighter than in the case of encrypting the wholeinput data, and settles the security issue. The range of encryption canbe shared simultaneously with sharing of the other parameters forencryption, and an increase in the workload therefor is very slight.

In particular, when the input data (application)is an RTP packet asmentioned above, if the header portion of the RTP packet is notencrypted, a UDP packet header and an IP packet header are added to theabove header—this provides for header compression, including the RTPpacket, during transmission as is the case with Secure RTP. Further,since the area of encryption can be set at the beginning of the sessionthrough negotiations with the receiving side unlike in the case ofSecure RTP, this scheme can also be applied versatily to otherapplications than the RTP packet.

Although in FIG. 11 the addition of the authenticator is followed byencryption, it is also possible to generate the authenticator afterencryption (S5) and add the authenticator to the encrypted packet (S7)as depicted in FIG. 13. In this case, at the receiving side theverification of the validity of the received data is followed bydecoding. When padding (S3) is necessary, it precedes encryption (S5).

The flow of the above-described selective security processing is shownin FIG. 14, in which, upon input thereto of data (S1), thetransmitting-side communication apparatus: shares parameters indicativeof the securing target of the input data with the receiving-sidecommunication apparatus via the communication channel (S2); performsecurity processing of part of the input data based on the sharedsecuring target parameters (S3); and transmits the input data (S4).

Second Embodiment

FIG. 15 illustrates a second embodiment of the present invention. Thisembodiment is adapted to be capable of supporting the selectiveencryption by extending the SSL scheme depicted in FIG. 5. The parametersharing part 34 in the first embodiment further comprises: a handshake(Handshake) part 34 a for negotiating with the receiving-sidecommunication apparatus 40 about authentication processing andencryption/data authentication parameters; a change cipher (ChangeCipher) part 34 b for validating the encryption/data authenticationparameters; an alert (Alert) part 34 c for indicating an event error; afirst application data part 34 d for transparently sending and receivingupper-layer application data; and a first record (Record) part 34 e forsending and receiving protocols of the above-mentioned four parts 34 a,34 b, 34 c and 34 d via the lower layer part (transport part) 32.

The first record part 34 e uses, as its protocol data format, the sameformat as that of the SSL record part shown in FIG. 6. The handshakepart 34 a negotiates with the receiving-side communication apparatus 40about the encryption/data authentication parameters that are used in thefirst record part 34 b and the second record part(encryption/authenticator adding part) 33. And the change cipher (ChangeCipher) part 34 b validates the encryption/data authenticationparameters of the first record part 34 e and the second record part 33.That is, it starts and indicates encryption to the receiving side. Tothe first record application data part 34 e are input a protocol messageof the handshake part 34 a and application data that does notnecessitate the selective encryption in the first application data part34 d.

The transmission and reception of application data that necessitatesselective encryption are performed, independently of the above-mentionedprotocol data, by a second record part, that is, by theencryption/authenticator adding part 33. A second application data 37 isto transparently send and receive the data packet of a high-order secondapplication part 31 b to and from the second record part 33. Further,unlike the first record part 34 e the second record part, that is, theencryption/authenticator adding part 33 does not add a new header to theinput data but performs the encryption/authenticator generationprocessing alone. The parameters shared by the first record part 34 eare used for the encryption/data authentication processing in the secondrecord part 33. The encryption/data authentication processing is thesame as in the first embodiment.

The handshake part 34 a starts the parameter sharing procedure usingplaintext communication with the receiving-side communication apparatus40, and may protect the communication using sharedencryption/authentication parameters halfway through the procedure amongapplications an application data packet which is not required to havethe real time property and is not frequently sent, such as HTTP, FTP,Telnet or RTSP (a protocol for opening the RTP session), is input from afirst application part 31 a via the first application data part 34 d tothe first record part 34 e, which encrypts the input packet in itsentirety based on the shared parameters and adds the encrypted packetwith the header 20H of the record part as depicted in FIG. 6, thereafterproviding the packet as a record protocol packet to the transport part32. Incidentally, the receiving-side communication apparatus 40 has thesame construction as depicted in FIG. 15 except that theencryption/authenticator adding part 33, which is the second recordpart, is a decoding/verification part.

Third Embodiment

FIG. 16 illustrates a third embodiment of the present invention. Thisembodiment negotiates with the receiving-side via the first applicationpart 31 a as of RTSP or HTTP to share the encryption/authenticatoradding parameter that are applied to the application data of the secondapplication part 31 b. For example, encryption parameters in FIG. 8 canbe transmitted to the receiving-side apparatus 40 by encrypting them bythe public key of the receiving-side communication apparatus 40 andembedding the encrypted parameters in the protocol message body.

It is also possible to provide both of the encryption/authenticatoradding part and the decoding/verification part in one communicationapparatus. While the above embodiment performs, for data security, bothof encryption and data authenticator addition, only one of them may alsobe utilized. The respective parts of the communication apparatuses 30and 40 may be implemented by executing programs on a computer.

EFFECT OF THE INVENTION

As described above, the present invention provides security for aselected portion of data, permits versatile transmission data protectionunspecific to a particular application, and enables header compressionwhen employed in mobile communications in particular.

1. A data-securing communication apparatus comprising: an applicationpart for generating an application data to be transmitted; parametersharing means for sharing parameters for securing input data includingsaid application data with a receiving-side data-securing communicationapparatus via a communication channel; securing means for securing saidinput data based on said shared parameters; sending means for sendingthe output of said securing means through said communication channel ina predetermined form; and wherein said parameter sharing meansnegotiates and shares, with the receiving-side data-securingcommunication apparatus, parameters indicative of a portion of saidinput data to be secured and said securing means is adapted toselectively secure the portion of said input data based on said sharedparameters.
 2. The data-securing communication apparatus as claimed inclaim 1, which is further provided with means for determining saidportion of input data in accordance with the kind of said applicationdata.
 3. The data-securing communication apparatus as claimed in claim1, which is further provided with means for determining said portion ofinput data in accordance with the network to which said apparatus isconnected.
 4. The data-securing communication apparatus as claimed inclaim 1, wherein said portion of input data is a portion for encryption,said receiving-side communication apparatus being a decrypting apparatusand said securing means being encryption means.
 5. The data-securingcommunication apparatus as claimed in claim 4, wherein said input datais an RTP packet and said portion for encryption is data except an RTPheader.
 6. The data-securing communication apparatus as claimed in claim4, wherein the criterion for determining said portion for encryption isthe transmission rate of the communication channel of said network. 7.The data-securing communication apparatus as claimed in claim 1,wherein: said portion of input data is a portion for authentication ofsaid input data; said receiving-side data-securing communicationapparatus is a data verification apparatus; said securing means is meansfor calculating an authenticator from said portion for authentication ofsaid input data; and means for outputting the input data after addingthereto said authenticator.
 8. A data-securing communication apparatuscomprising: receiving means for receiving data through a communicationchannel; parameter sharing means for sharing parameters for securingdata with a transmitting-side data-securing communication apparatus viaa communication channel; and means for decoding and/or verifying saidreceived data based on said shared parameters; wherein said parametersharing means negotiates and shares, with said transmitting-sidedata-securing communication apparatus, parameters indicative of aportion of said received data to be secured, and said means for decodingand/or verifying is adapted to selectively decode and/or verify theportion of the received data based on the shared parameters.
 9. Adata-securing communication method comprising: (a) generatingapplication data to be transmitted at a transmitting side; (b) sharingparameters for securing input data including said application data witha receiving side via a communication channel; and (c) securing saidinput data based on said shared parameters; and (d) sending out saidsecured data through said communication channel to the receiving side:in the receiving side; (e) receiving data through said communicationchannel; (f) sharing parameters for securing data with the transmittingside via the communication channel; and (g) decoding and/or verifyingthe received data based on said shared parameters; wherein said sharingstep (b) includes step for negotiating and sharing, with the receivingside, parameters indicative of a portion of said input data to besecured; said securing step (c) includes step for selectively securingthe portion of input data based on said shared parameters; (h) said step(f) includes a step of negotiating and sharing, with said transmittingside, the parameters indicative of the portion of data, and said step(g) is a step for selectively decoding and/or verifying the portion ofthe received data based on said shared parameters.
 10. The data-securingcommunication apparatus as claimed in claim 2, which is further providedwith means for determining said securing target in accordance with thenetwork to which said apparatus is connected.
 11. The data-securingcommunication method of claim 9, wherein said portion of said input datais a portion for authentication, and said securing step (c) is a stepfor: calculating an authenticator from said portion of said input dataand said step (d) is a step for outputting said input data after addingthereto said authenticator.
 12. The data-securing communicationapparatus as claimed in claim 2, wherein said securing target is atarget for encryption, said receiving-side communication apparatus beinga decoding apparatus and said securing means being encryption means. 13.The method as claimed in claim 12, wherein said received data is an RTPpacket and said selective decoding is performed for data except an RTPheader of said RTP packet.
 14. The data-securing communication method asclaimed in claim 10, wherein said input data is an RTP packet and theselective encryption is performed for data except an RTP header of saidRTP packet.
 15. The method of claim 12, wherein said received datacontain authenticator and said portion is a portion for authentication,and said step (c) is a step for: verifying the validity of datacontained in said portion for authentication of the received data bydata of said portion and said authenticator contained in said receiveddata according to said parameters.
 16. The data-securing communicationapparatus as claimed in claim 3, wherein said securing target is atarget for encryption, said receiving-side communication apparatus beinga decoding apparatus and said securing means being encryption means. 17.The data-securing communication apparatus as claimed in claim 10,wherein said securing target is a target for encryption, saidreceiving-side communication apparatus being a decoding apparatus andsaid securing means being encryption means.
 18. The data-securingcommunication apparatus as claimed in claim 2, wherein: said securingtarget is the range of authentication of said input data; saidreceiving-side data-securing communication apparatus is a dataverification apparatus; said securing means is means for calculating anauthenticator from said range of authentication of said input data; andmeans for outputting the input data after adding thereto saidauthenticator.
 19. The data-securing communication apparatus as claimedin claim 3, wherein: said securing target is the range of authenticationof said input data; said receiving-side data-securing communicationapparatus is a data verification apparatus; said securing means is meansfor calculating an authenticator from said range of authentication ofsaid input data; and means for outputting the input data after addingthereto said authenticator.
 20. The data-securing communicationapparatus as claimed in claim 10, wherein said securing target is therange of authentication of said input data; said receiving-sidedata-securing communication apparatus is a data verification apparatus;said securing means is means for calculating an authenticator from saidrange of authentication of said input data; and means for outputting theinput data after adding thereto said authenticator.
 21. Thedata-securing communication method of claim 9, wherein said portion ofinput data is a portion for encryption, and said securing step (c) is astep for selectively encrypting the portion of input data based on saidshared parameters.
 22. The method of claim 9, wherein said portion is aportion for encryption, and said step (g) is a step for selectivelydecoding the portion of the received data based on the sharedparameters.